Subject: [External] : 回复: JI-9079384: Request for Standalone Reproducer – Netty SocketDispatcher Issue
From: 房 成进 <[email-masked]>
To: Raghu Kale <[email-masked]>
Date: Fri, 17 Oct 2025 03:40:40 +0000

Hi，

So far, we've reproduced this issue only once in a stress testing environment.

Here is our troubleshooting approach. Please see if it helps.

  1.
jstack - l 12304 > jstack.log => java thread id = 161, native thread id = 0x1f4fa, blocking on read0

     2. printf %d 0x1f4fa => nid is 128250 in decimal

  1.
strace -T -e trace=read -p 128250 => read is stucking on fd0

  2.
fd0 is a pipe connected to the supervisor. Our process was started by the supervisor (pid=104015), which then replaced the stdin (fd0) with a pipe. This is the default behavior of the supervisor. We think fd0 has never been closed and reused.

       5. Then we dump heap, the heap dump is quite large (about 2GB), so I'm not sure if you need it. We use visualvm to analysis the heap, in order to identify where the file descriptor 0 was misused.
       JNI method SocketDispatcher.read0, param fd is tracing back to fd in object sun.nio.ch.SocketChannelImpl. But this fd in java heap is 3465, NOT 0.

        6. Finally We try to read open jdk source code. In SocketDispatcher.read0 jni method,  can fdval method return 0? Maybe GC moved the fdo object，jni get fd from a wrong adress?
        Based on the above analysis, we would like to consult you on the following questions:
        1. Have you encountered a similar issue before?
        2. Could you please verify if our analysis is correct and whether you think this could be a JDK-related issue?
        3. Are there any tools or approaches you would recommend to help us root-cause this if it occurs again?

         Furthermore, something about this issue:
        1. We had been running Apache RocketMQ on JDK 8 for about one to two years. Last month, we upgraded our production environment to JDK 17.0.2, and the issue occurred since then.
        2. We rolled back the JDK to version 8 yesterday and are monitoring for any recurrence. We consider it highly unlikely that the issue will reappear.